1. The Field of the Invention
The present invention generally relates to messaging systems. More particularly, the present invention provides for storing message rules in global form for ease in transferring rule data between servers.
2. Background and Related Art
Electronic messaging systems (e.g., e-mail, messaging boards, etc.) have become an increasingly popular way to communicate. Business users increasingly rely on electronic messages to share ideas, transmit documents, schedule meetings, and perform a multitude of other every day tasks.
These tasks may be accomplished by a variety of software programs. For example, e-mail programs facilitate the transmission of messages between users. Messaging-enabled scheduling programs allow users to request and schedule meetings and appointments via electronic messages. Computer programs known as desktop information managers attempt to coordinate the growing stream of electronic
The increased reliance on electronic messaging has resulted in a great increase in the number of electronic messages a user sends and receives daily. For example, similar to postal mail advertising and telephone solicitations, electronic message recipients are increasingly being subject to unsolicited mass mailings, commonly referred to as “SPAM.” Due in part to the extreme ease and insignificant cost for not only sending electronic messages across extremely large numbers of addresses, but also because of the ease and low cost for obtaining or exchanging e-distribution lists, a user can expect to receive considerably large amounts of SPAM over a short period of time. Accordingly, users desire effective ways to process their messages without spending a lot of time sorting through their inbox, deleting, filing, forwarding, and responding to their messages. For instance, users would like the ability to delete or otherwise store in a separate folder unsolicited electronic messages such as SPAM.
Typical systems provide mechanisms for processing messages in accordance with rules or commands that automatically execute specific tasks or actions when user-provided criteria or conditions are met. For example, a user may want to file all messages from a certain user or regarding certain subject matter in a specific folder. As such, a user can create a list of known e-mail or IP addresses, and/or a list of specific terms that each incoming message should be scanned for, and such conditions identified. The rule then specifies a particular action to take once the conditions are met, e.g., delete, store in a particular folder, forward to other users, etc.
Certain messaging systems store and execute these rules at the server where the incoming messages are initially received. In order to modify the rules, a client must make a request to the server to receive the rules for modification. After receiving and modifying the rule, the client then sends the rules back to the server where they are stored and executed in a format specific to the server.
Although these rule-based messaging systems are reasonably effective and user-friendly, these systems also have various shortcomings. For example, some services impose aggregate size limitations on rules. Accordingly, an obvious solution to such problem would be to lift the aggregate size limitation; however, even if this limitation were removed, other architectural constraints limit the size of the rules. For instance, some systems provide that when a user desires to make changes to the rules, a server communicates the rules to a client through a table interface as rows within a rules table. Due to existing architectural constraints, however, many systems don't allow for rows on a table to be streamed. Accordingly, the individual size of rules (as well as the aggregate size) is limited to the size of the data buffer for sending a packet of data from the server (e.g., a Remote Procedure Call (“RPC”) buffer). Such restrictions become particularly problematic when large rules with extensive listings of addresses or other information are desired, e.g., white lists or black lists.
Clearly one solution to overcoming the deficiencies of current messaging systems would be to redefine the architecture itself. There are, however, several shortcomings associated with such a solution. For example, such modification may require most if not all users to update their client software. Accordingly, users with legacy clients that implement the legacy rules would not be supported with the change in the rule architecture. Further, those that wanted to continue using the rules would be forced to purchase updates or switch services, thus pushing additional costs on the user. Moreover, there are instances where the server/client software implementation of the system cannot be modified in an elegant way because design choices preclude simple solutions to new problems.
Another drawback of current messaging systems is that rules and other data are stored on the server in a form specific to the server. For example, the global identifiers within at least the action structures for rules are translated by a service provider into server specific form, which are stored on the server as such. Accordingly, when a client request rule modifications, the identifiers on the server (e.g., an identifier for the destination folder in the event of a move action) must be translated from the server's specific form back to the global form. Because the rules are stored on the server with the identifiers within'the action structures in the server specific form, rules cannot simply be transferred from one server to another. As such, if a client switches services, or even changes servers within the same service, identifiers must be translated back to the global form and then sent to the new server, which then translates the global identifiers into its server specific form. This creates a tremendous amount of overhead and inefficient use of system resources.
Still another drawback of typical messaging systems is that there is little or no flexibility in controlling Anti-SPAM rules. For example, typical messaging systems set the conditions and actions for an Anti-SPAM rule such that if a message is rated above a predetermined threshold as SPAM, then the message is simply sent to a junk folder or deleted. There is no ability to decouple the SPAM confidence level (i.e., the confidence level that a message. includes unsolicited or unwanted content) from the actions, e.g., to move the SPAM to a junk folder or delete it. Further, there is no flexibility in the actions carried out in the event the SPAM confidence level is above the predetermined threshold, i.e., there is just send to junk folder or delete it.